ci: add workflow for lambda layer publish and yank #870

dbschmigelski · 2025-09-15T20:33:26Z

Description

This pull request introduces new automated workflows for publishing and managing Strands Agents Lambda layers across AWS regions, Python versions, and architectures.

The publishing workflow, defined in publish-lambda-layer.yml, automates layer creation across 136 distinct variants, encompassing 17 regions, 2 architectures, and 4 Python versions. To prevent accidental deployments, the workflow requires explicit version confirmation through the phrase "Create Lambda Layer {version}".

For cases where layer access needs to be restricted, we've implemented a yanking workflow in yank-lambda-layer.yml.

The implementation supports 136 Lambda layers, covering combinations of Python versions (3.10, 3.11, 3.12, 3.13), architectures (x86_64, aarch64), and all 17 non opt-in AWS regions. Each layer follows the naming convention "strands-agents-py{VERSION}-{ARCH}-all" and maintains version synchronization across all variants.

Note: The review and configuration of the IAM role will be conducted outside of the GitHub workflow system to ensure proper security controls and compliance with organizational policies.

Related Issues

#636

Documentation PR

strands-agents/docs#255

Type of Change

New feature

Testing

How have you tested the change? Verify that the changes do not break functionality or introduce warnings in consuming repositories: agents-docs, agents-tools, agents-cli

Tested in dbschmigelski/sdk-python running both publishing and yanking with various configurations.

https://github.com/dbschmigelski/sdk-python/actions/runs/17740370035
https://github.com/dbschmigelski/sdk-python/actions/runs/17740080550

I ran hatch run prepare

Checklist

I have read the CONTRIBUTING document
I have added any necessary tests that prove my fix is effective or my feature works
I have updated the documentation accordingly
I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
My changes generate no new warnings
Any dependent changes have been merged and published

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Unshure

Looked into some limitations around lambda layers, and it looks like there is a default limit of 75GB for code storage across lambda layers and lambda code. If we are bundling 8 versions of the layer per region, do we know when we are at risk of hitting this limit?

Also, can we create an issue to track adding an integ test for the deployed lambda layer?

Unshure · 2025-09-22T18:25:49Z

.github/workflows/LAMDBA_LAYERS_SOP.md

+
+1. **Determine target layer version**: Check existing variants to find the highest layer version
+2. **Buffer deployment**: Deploy new variants multiple times until layer version matches existing variants
+3. **Example**: If existing variants are at layer version 5, deploy new variant 5 times to reach version 5


Why do we need to buffer deployments? If we add a new variant, no one would could be depending on versions before that one. I would like to avoid backfilling versions if possible

If we don't backfill then we will need to maintain a mapping of each new variant with the version it maps to. Its mostly for a communication issue. Our docs page will be quite messy without it - but if you have an idea for how we could display that cleanly I'm all ears

With the backfill approach we just have one line item per pypi version. And can have a simple list of

"Variants with XYZ introduced in version ABC"

Unshure · 2025-09-22T18:26:51Z

.github/workflows/LAMDBA_LAYERS_SOP.md

+
+## Deployment Process
+
+### 1. Initial Deployment


Would be nice to note the exact versions of dependencies included in the layer, in case certain dependency versions come with quirks or bugs. We should also note the version of strands being released in each layer.

Updating to print here. Storing this long term means introducing a database of some kind. So I want to avoid the hurdles with that until we get feedback from customers that they need it

If we embed the strands version we'll be creating a new lambda layer for each pypi release rather than a new version. Thats not a pattern I've seen elsewhere

.github/workflows/publish-lambda-layer.yml

Unshure · 2025-09-22T18:31:14Z

.github/workflows/publish-lambda-layer.yml

+      matrix:
+        python-version: ${{ inputs.python_version == 'ALL' && fromJson('["3.10", "3.11", "3.12", "3.13"]') || fromJson(format('["{0}"]', inputs.python_version)) }}
+        architecture: ${{ inputs.architecture == 'ALL' && fromJson('["x86_64", "aarch64"]') || fromJson(format('["{0}"]', inputs.architecture)) }}
+        region: ${{ inputs.region == 'ALL' && fromJson('["us-east-1", "us-east-2", "us-west-1", "us-west-2", "ap-south-1", "ap-northeast-1", "ap-northeast-2", "ap-northeast-3", "ap-southeast-1", "ap-southeast-2", "ca-central-1", "eu-central-1", "eu-west-1", "eu-west-2", "eu-west-3", "eu-north-1", "sa-east-1"]') || fromJson(format('["{0}"]', inputs.region)) }}


Why would we ever not deploy to all regions?

If one action failed because of some networking issue. We could go back and just deploy that one so all the version are still aligned

Unshure · 2025-09-22T18:34:37Z

.github/workflows/publish-lambda-layer.yml

+          LAYER_NAME="strands-agents-py${PYTHON_VERSION//./_}-${ARCH}"
+          ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+          BUCKET_NAME="${{ env.BUCKET_NAME }}-${ACCOUNT_ID}-${REGION}"
+          LAYER_KEY="$LAYER_NAME/v${{ inputs.package_version }}/lambda-layer.zip"


What if we need to re-release a layer version with the same strands package version? Will this key collide? Can we infer what the new layer version will be, and add that to the key name here?

It will overwrite, this would not impact the earlier version though.

I'll see how can I dedupe

Unshure · 2025-09-22T18:35:52Z

.github/workflows/publish-lambda-layer.yml

+
+      - name: Download and install package
+        run: |
+          pip install strands-agents==${{ inputs.package_version }} \


Can we print out and record the dependency versions for each lambda layer?

Updating to print here. Storing this long term means introducing a database of some kind. So I want to avoid the hurdles with that until we get feedback from customers that they need it

codecov · 2025-12-09T00:21:21Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

dbschmigelski had a problem deploying to auto-approve September 15, 2025 20:33 — with GitHub Actions Failure

dbschmigelski mentioned this pull request Sep 15, 2025

feat(deploy): add lambda layers page strands-agents/docs#255

Open

6 tasks

dbschmigelski marked this pull request as ready for review September 15, 2025 20:36

dbschmigelski changed the title ~~Sdk main~~ ci: add workflow for lambda layer publish and yank Sep 15, 2025

dbschmigelski had a problem deploying to auto-approve September 16, 2025 02:24 — with GitHub Actions Failure

Unshure requested changes Sep 22, 2025

View reviewed changes

github-actions bot added the size/m label Dec 9, 2025

dbschmigelski had a problem deploying to auto-approve December 9, 2025 00:19 — with GitHub Actions Error

github-actions bot added size/xl and removed size/m labels Dec 9, 2025

dbschmigelski had a problem deploying to auto-approve December 9, 2025 15:01 — with GitHub Actions Failure

ci: add workflow for lambda layer publish and yank

17a2839

dbschmigelski force-pushed the sdk-main branch from 996e86f to 17a2839 Compare December 9, 2025 15:04

github-actions bot added size/m and removed size/xl labels Dec 9, 2025

dbschmigelski had a problem deploying to auto-approve December 9, 2025 15:05 — with GitHub Actions Failure

dbschmigelski had a problem deploying to auto-approve December 9, 2025 15:10 — with GitHub Actions Failure

dbschmigelski temporarily deployed to auto-approve December 9, 2025 15:17 — with GitHub Actions Inactive

ci: add workflow for lambda layer publish and yank #870

Are you sure you want to change the base?

ci: add workflow for lambda layer publish and yank #870

Uh oh!

Conversation

dbschmigelski commented Sep 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issues

Documentation PR

Type of Change

Testing

Checklist

Uh oh!

Unshure left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Dec 9, 2025

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dbschmigelski commented Sep 15, 2025 •

edited

Loading